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(57) Abstract: The present invention provides a system for creating an application software environment without changing an 
operating system of a client computer, the system comprising an operating system abstraction and protection layer, wherein said 
absiraclion and prnieclion layer is interposed between a running software application and said operating system, whereby a virtual 
environment in which an applicaiion may run is provided and application level interactions are substantially removed. Preferably, 
any changes directly to the operating system are selectively made wilhin the context of the running application and the abstraciion 
and protcciion layer dynamically changes the virtual environment according lo administrative settings. Additionally, in certain em- 
bodiments, the system continually monitors the use of shiu-ed system resources and acts as a ser\'ice to apply and remove changes 
10 system components. The present thus invention defines an "Operating System Guard." These components cover the protection 
semantics required by DLLs and other shared library code as well as system device drivers, fonts, registries and other configuration 
items, files, and environment variables. 
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OPERATING SYSTEM ABSTRACTION ANB PROTECTION LAYER 

This application is a continuation-in-part of U.S. Patent Application No. 

09/456,181 , the entirety of wliich is incorporated herein by reference as if ftUly 

set forth. 

The present invention icJaiGS to computer software, and more particularly to 
operating system software. 

BACKGROUND OF THE INVENTION 

In many environments, but particularly in enviromnents where an application is 
ddivered via a networl^ the most in5)ortant feature is an ability to run applications on the fly, 
vvithout a con5)lex installation. Typicafly, in certam prior art systems^ great pains were taken 
to modify a cfient system to appear as if a program was installed, or to actually mstall the 
software itself and then back out these modifications to restore the oiignal configuration. In 
doing this, multiple problems present themselves: conflicts between an application and the 
computer's current configuration, multiple histances of the same or different applications, 
complexity of the back out process requires an application to be put through a rigorous process 
to ensure all of its modifications can be accounted for, and the use of shared files and system 
con^onents by multyle applications conpKcates back out and the installation process. 
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SUMMARY OF TEDE INVENTION 

The present iBvention provides a system for creatiDg an application software 
eavironmeiit v^dthout diangmg an operating system of a client con^uter, the system 
coi^oprising an operating system abstraction and protection layer, wherem said abstraction 
and protection layer is interposed between a running software application and said 
operating system, whereby a virtual environment in which an application may run is 
provided and application level interactions are substantially removed. Preferably, any 
changes directly to the operating system are selectively made within the context of the 
rmming application and the abstraction and protection layer dynamically changes the 
virtual environment according to administrative settings. Additionally, in certain 
embodiments, the system continually monitors the use of shared system resources and 
acts as a service to apply and remove changes to system components. 

Thus, for example, in embodiments within Windows-based operating systems, 
and wherein all operations to the Windows Registry are through the Win32 API, the 
system preferably provides a means for hooldng functions, whereby each time said 
functions are invoked another fimction or application intercepts the call, and the system 
most preferably hooks each appropriate API function to service a request whether made 
by an application run fiom a server or if made by an application against a configuration 
key being actively managed 

In other preferred embodiments of the present invention, additional fimctionality 
is provided, such as those embodiments wherein the operating system abstraction and 
protection layer manages the integration of multq)le instances of an application by 
recognizing how many instances of an application are running, and in such embodiments 
most preferably it also avoids making changes on startup and shutdown unless there is 
only one application instance running. In this embodiment it is also possible to support 
multi-us^r operating systems in which multiple instances of an application can be ruiming 
on behalf of different users. 



-2- 



CA 02465880 2003-11-14 



WO 02/093369 PCTAJS02/15378 

Thus^ the operating system abstraction and protection layer presents an 
environment to an application that aj)pears to be an installation environment without 
perfonning an installation, whereby a '"pseudo installation" is created in which all of the 
settings are brought into a virtual environment at the time the application runs. Or in the 
case of an installed application, acts to dynamically modify the behavior of the 
application at run-time. Preferred embodiments provide a means for preventing 
information on the client con^uter from interfering or modifyiag the behavior of an 
application, and most preferably provide a means for dynamically changing the virtual 
esnvironment according to administrative settings. As mentioned above, in certain 
embodiments it will be possible to have more than one instance of a single sofiwaxe 
application running on the same client computer, even if it was not origmally authored to 
do. so. In such embodiments^ shared, controlled contexts are provided in which at least 
two of said instances of a single application share one or more virtual settings. . 



BRIEF DESCRIPTION OF THE DRAWINGS 

EIG. 1 is a block diagram schematic showing the relative rdationshq) of the present 
invention, an opiating system and a software application; 

FIG. 2 is a block diagram schematic showing 

FIG. 3 is a block diagram schematic showing 

FIG. 4 is a block diagram schematic showing 

DETAiUED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Referring now to FIG. 1, there is illustrated a block diagram schematic sho\Nnng the 
relative relationship of the present invention, an operating system and a software application. 
Preferred embodiments of the present invention provide an operatiag system abstraction and 
protection layer 100 denominated aa **Operatmg System Guard." Ihtemally, many operating 
systems 10 pro\dde 6ult domains to protect applications 50 from affecting each other when 
nm. However, Glared system resomxes and many other operating system features aQow this 
protection domain to be congiromisei An operating system abstraction and protection layer 
100 vwll provide an additional, programmaticaUy controlled barrier between applications 50 to 
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lemove most appKcation level interactions. Disposed between the application 50 and operating 
system 10 the operating system abstraction and protection layer 100 selectively allows 
changes directly to the operating system 10, versus containing the change within the context of 
the running application- For one cxBrnple, in Windows-based systems, all operatioais to the 
Windows Registry are typically done through the Win32 API As ej^lained below, system 
functions like QueryRegEx and GktProfBieString can be hooked so that each time they are 
invoked, another function or application mtercepts the calL The Operating System Guard 100 
of the present invention will hook each appropriate API fimction to service the request, if 
made by an appUcation bring actively managed or if made by an application against a 
configuration item bdng actively managed In this way, unless ejqplidtly configured to do so, 
the present invention can create the application environment wMout making any actual 
changes to the end-user's system. Also, any modificatians made at run-time by the 
application can be persisted or removed easily. 

As used herein the term "Operating System Guard" defines a layer between a 
running application and the operating system of a target con5)uter or client conqjuter that 
provides a virtual environment in which an appUcation may run. This virtual 
environment has several purposes. First, it prevents a running application from making 
changes to the client computer. If an application atten5)ts to change underlymg operatmg 
system settings of a client computer, such settings are protected and only '"made" in the 
virtual environment. For exanqple, if an application attempts to change the version of a 
shared object like MSVCRT.DLL, this change is localized to the application and the code 
resident on the client con5)uter is left untouched. 

Second, the invention presents an enviroimient to a running application that 
appears to be an installation envhonment without perfoimmg an installation, and is thus a 
'"pseudo mstallation" or *^nstallation-like.'' All of the settings are brought into a virtual 
environment at the time the application being served runs, or just-in-time when the 
appHcation needs the particular settmg. For example, if a computer program such as 
Adobe Photoshop® expects to see a set of Windows Registry entries under 
H^YJLOCAL_MACHI^ffi\So^hvare\A^ and they are not there on the client 
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conxputeT since Photoshop was never installed, a system made in accordance with this 
aspect of the present invention will "show" those registry entries to the Photoshop 
programming code exactly as if they were resident on the client corrqputer. 

Nfext, the invention prevents mformation that may exist on the clientAisers • 
machine from interfering with or modifying the behavior of an application. For 6xaiiQ)le, 
if the user has already existmg registry entries under: 

I^KEYJLOCAL_MACHI>ffi\Softwa^^ 
for an older version of Photoshop, but now wishes to operate a newer version, these 
entries can be hidden from the new application to prevent conflicts. 

Finally, the present invention unlocks application behavior that may not exist as 
the application is currently written. It does this through the ability to dynamically change 
the virtual environment accordmg to admmistrative settings. For example;, in a typical 
iastance of an enterprise software application, a client application may expect to read a 
settibttg for the address of the database to which the user should connect from a setting in 
the registry. Because this registry key is often stared m HKEYJLOCALJVIACHINE, the 
setting is global for the entire client computer. A user can only connect to one database 
without reinstalling the client, or knowmg how to modify this registry key, and doing so 
each time they wish to run the application. However, by implementing the present 
"invention, two instances of the application may now run on the same client computer, 
each connecting to a different database. 

CONTEXTS 

In providing this functionality, each application is able to hm in a private context 
within the system. To the application, it has its own private view of what the system 
looks like and its behavior. The present invention provides this by its inherent nature. 
Referring to FIG. 2, two separate applications 52,54, or two instances of the same 
application (50 illustrated m FIG. 1), can be provided private contexts in which they will 
appear to have separate or differing copies of system services, configuration and data. In 
the preferred embodiment, this is the default behavior of the system. 
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By extending this concept, the Operating System Guard 100 of the present 
invention can also provide shared, controlled contexts in which two or more applications 
52,54 can share some or all of their virtual setthigs. This is important for application 
suites such as Microsoft Office, or for applications that perfbnu dififerently in the 
presence of other applications. For example, many applications use Microsoft Word as 
an engine for doing Mail Merge or document creation functionality. The applicatidn 
must know about the installation or presence of Word and be able to tap into its 
fimctions. In the preferred embodiment, two instances of the same application will share 
a smgle context by default, while two separate applications will maintam private 
contexts. Referring to PIG. 3, the two applications 52,54 can run while the Operating 
Jystem Guard 100 provides a shared view of the available system resources. 

)ESIGN 

As illustrated in FIG. 4, the Operating System Guard is conqjrised of the 
bllowing subsystems: core 102, configuration manager 104, file manager 106, shared 
object manager 108, device manager 110, font manager 112, process manager 120, 
irocess environment manager 114, loader 116, and recovery manager 118, With the 
xception of the core 102, the process manager 120, and the loader 1 1 6, all other 
ubsystems are elements of the Virtualization System described in iurther detail below, 
fhe core 102 is piimarily responsible for managing applications and their context as 
lefined by the configuration files. 

The process manager 120 provided by the Operating System Guard allows the 
•ore 102 to be informed of any process or thread event that may be of mterest. It also 
provides an abstraction layer to the operating system-dependent implementations for 
aanaging a process space and handling thread processing. Processes may be grouped 
ogether into application bmidles. An application bmidle is a group of processes which all 
hare their virtual resources with each other. Hor example, Microsoft Word and Microsoft 
ixcel may want to share the virtual registry and virtual file system to be able to work 
ogether ^as an application suite. The process manager 120 calls these application bundles 
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"applications''. The mfoimation about an application exists until the process manager 120 
is told to release the application. If another process needs to be loaded into the appfication 
bundle, it may do so as long as the application has not been released. 

The loader subsystem 116 of the present invention is used to allow virtual 
environments to be transferred into and out of the running system. Each of the 
VirtuaUzation Subsystems is capable of serializmg its configuration for the loader 116, 
and retrieving it through the reverse process. In addition, the loader 1 16 is capable of 
staged loadmg/unloading and combining the results of individual stages into one single 
environment description. 



REGISTRY AND CONMGURATION 

implications require varying amounts of configuration information to operate 
proprfy. Anywhere from zero to thousands of configuration records exist jfor which an 
application can read its configuration On Windows, there are two common places for 
configuration mformation, the Windows Registry and system level initialization files 
wiaud and systemini In addition, the \WIhroOWS\SYSTEM directory is a common 
place for applications to write application specific configuration or initialization files. 
Applications will also use configuration or data files in their local application directories 
to store additional configuration information. Often this information is diS5cu]t to deal 
with, as it is in a proprietary format. On platforms other than Windows, there is no 
equivalent of the Registry, but common directories exist for configuration mformation. X 
Wmdows has an app-defaults directory. Macintosh has the System Folder, and other 
operating systems will have corresponding elements. It is important to note that on most 
UNIX systems, each individual application 52,54 will most often store its own 
configuration 152,154 locally, as seen in FIG. 2. 

The present invention, in one embodiment, includes a virtual Windows Registry 
con5)onent, which will provide a fiill function registry to an application, but prevent 
modification to the underlying system registry. All keys that an application e?q)ects to 
access will be present, but may only exist in the vhtual re^stry. In this way, the 
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Operating System Guard 100 of the present invention and the Windows Registry fonn a 
two-stage process for accessing the registry. If an application needs access to a key, it 
will query the Registry. The Operating System Guard will respond with the key and its 
vahie if it knows it. Otherwise, it will aUow the request to pass through to the Windows 
Registry. If an attract is made to modify the value, the Operating System Guard will 
allow the modification to occur to itself only. The next time the application accesses the 
key, it will be present in the Operating System Guard and the request wilt not flow 
through to the real Registry, leaving it untouched. 

The keys that the Operating System Guard uses are specified in three separate 
sections. These Operating System Guard keys are specified as conomands in these 
sections to modify an existing key, delete the presence of a key, or add a new key to the 
registry, fiithisway, the virtual registry can appear exactly as the system intends. This is 
important as the presence or absence of a key can be as important as the actual value of 
the key. 

Iq the preferred embodiment, the Operating System Guard first loads a data file 
that contains basic registry entries for the application. Then a second data file is loaded 
that contains the user's preferences. KnaUy, the Operating System Guard can optionally 
load a set of keys that include policy items that the user is not allowed to override. The 
three files load on top of each other Avith duplicate items in each file overriding items in 
the file before it. The first time a user nms an application, the second data file will not 
exist because there wiU be no user-specific iaformation, only application defaults. After 
each session, though, the Operating System Guard will save the user's changes, 
generating that second data file for use in fixture sessions. 

Configuration files can be modified in two ways. First, the file can be edited 
directly by an application. In this scenario, the Operatiag System Guard File subsystem 
described below will address the modification made to the file. Second, in the preferred 
embodiment, an application can call the Windows API femily of caUs GetProfileStting, 
WriteProfileString, or others to modify these files. la this case, the Operating System 
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Guard of the present invention performs exactly as described above intercepting these 
calls and servicing them from within. 

SHARED OBJECTS 

Many components used by operating systems and running applications are shared 
across several appKcations or instances. In general, this is a very good idea. B saves disk 
space, not requiring many copies of the same file. It also provides the ability for 
operating system vendors and third parties to create and distribute libraries of commonly 
used code. On the Windows platform. Dynamic Link Libraries, DLLs, are often shared 
within and across applications. On other platforms, the problem is the same. On the 
Macktosh, INTTs and other system components are loaded for applications. These 
conq^onents can have many versions, of which only one is used at a time. On UNIX 
systems, dynamic shared objects, e.g., ".so" library files, are used by applications to 
speed load time, save disk space, and for other reasons. Many programs use the defeuh 
'Tibc.so." However, this library file is typicaUy a symbolic link to some version of itself 
such as Kbc.so.3. In practice, this feature has created havoc. These shared con^onents 
have often gone through revision, with many versions of the same conq)onent available to 
be mstalled. Application authors have found their software to work with potentially only 
one or some of the versions of the shared con^onent. Thus, m practice, applications 
typically install the version they desire, overwriting other present versions. This 
potentially causes defaults in other apphcations running on a system 

On Windows 98, Windows 2000, Microsoft has created the Windows Protected 
File System (WPFS) to allow system admhiistrators to create a file called 
XXXX.LOCAL in the base dneaory of an application, where XXXX is the executable 
file name without the extension. This causes the Windows Loader to alter its method of 
resolving path references during LoadLibrary executions. This, however, is not suflBcient 
to cpn^jletely solve the problem. First, setting up the XXXX file is left to the knowledge 
of the system administrator, which varies widely. Second, a component version must 
undergo a rewmd back to the original, then mstall this component in the local directory, 
and then create the ".LOCAL" file. This is not a straightforward process for any but the 
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most basic coiBponents placed in WINDOWSXSYSTEM Also, this solution does not 
cover all of the needed fimctionaltty. During LoadLibrary, Windows uses different path 
resolution semantics depending on wliether the conq)onent was resolved as a result of an 
explicit or implicit LoadLibrary, and also ^'s^iether a Registry Key exists indicating that it 
is a named, or well-known, DLL. Iq this case, the LoadLibrary call will always resolve 
to the WINDOWS\SYSTEM directory. 

DLLs and other shared components also retain reference count semantics to 
ensure that a componeot is not touched unless no running applications refer to it. In 
practice, only applications from the operating system vendor and the operating system 
itself have done a good job of obeying this protocol 

As a general rule, it is desired to have a shared object always resolve to the 
correct con[5)onent. To provide this functionality it is required to understand the version 
of a component, or range of versions, that an application is able to Jftinction with. Then, 
vAiGn the application is to be run, the present invention should ensure that the con^onent 
is resolved correctly. It is accq)table, in the present invention, to automate the use of 
WPFS or other operating system provided capability, if desired. In this case, it is 
necessary to detect needed conqjonents and place them in the local file system This is 
more corcplex than just watching installation, as an mstallation program will often not 
install a con5)onent if the required one is ahready there. 

It is desired to identify a method to ensure that named objects are also loaded 
correctly. On the Windows platfonn, MSVCRT.DLL is a significant culprit within this 
problem area. If multiple versions of this object are maintained, the aforementioned 
Registry key can be dynamically changed, allowing the LoadLibrary fimction to resolve 
the correct conponent version. Another reasonable method of ensuring correct 
conponent loading is the dynamic editing of a process environment to use a valid search 
path. This search path vwll ensure that a local component is resolved before a system 
wide component Another possible method for resolution of the correct shared object is 
through the use of symbolic links. A symbolic link can be made for a shared component, 
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which is resolved at nm-tiiiie by the computer's file system to the needed component. 
Knally, the actual open/read/close requests for mformation ftom a shared object's file 
can be intercepted by the present invention and responded to dynamically for the correct 
version of the file which may exist on the local system or within the invention's 
subsystems. 

Several special forms exist. On the Windows platform, OLE, ODBC, MDXC, ... 
as well as a number of other vendor specific components, are written to be shared 
globally among several or all running processes. la the case of OLE, gohig as far as 
sharing data and memory ^ace between sqparate processes. OLE prevents more than 
one copy of itself running at a time, as do many of these components. OLE also has 
many bugs and features requiring a i^ecific version to be loaded for a specific 
application. la the present invention, an application is able to load whatever version of 
OLE is required, still enabling the shared semantics with other conc^onents u^g the 
same version of OLE. 

In general, unless specifically configured as such, shared objects should be loaded 
privately to ensure conflict prevention. Nothing about the method used to allow a 
con[^)onent to be loaded privately should prevent it fi:om being unloaded cleanly or 
correctly loading for another software application, whethw bemg actively m£uiaged by 
the Operating System Guard or not. In addition, if the system crashes it is required to 
recover firom this crash to a clean state, not having overwritten or modified the 
underlying operatiag system, 

HUES 

Many applications Tise data files within the apphcation to store configuration 
entries or other application data. The present invention provides a virtual file system 
much like the virtual registry described above. Before the application starts, the present 
invention can load a list of file system changes, hicludmg files to hide and files to add to 
the virtual environment or files to redirect to another within the virtual environment. 
Whenever the application accesses or modifies any files, the Operating System Guard 
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checks if the jBle must be redirected, and if so, in the prefeaed embodiment redirects the 
request to a location specified in die Operating System Guard configuration. 

If an application tries to create a new file or open an existing file for writing on a 
user's local drive, the C^erating System Guard must ensure that the file is actually 
created or modified hi the redirected location. If the application is reloaded at a kter time, 
this file mappmg must be reloaded into the Operating System Guard virtual environment. 
When the request is to modify an existing file, which resides on a user's local drive, the 
Operating System Guard must copy the file in question to the redirection point before 
continuing with the request. The redirected files may not be of the same name as the 
origmal file to ensure safe mapping of file paths. la the preferred embodiment, INI files 
are handled in this way to offer maTomum system security whUe allowing maximum 
application con^atibility. 

The present invention is particularly iisefiil for applications delivered over a 
network. In such implementations it is important to understand that sofi?ivare applications 
are made p{ several kmds of data, where the bulk of the files a software application uses 
are most preferably mounted on a separate logical drive. Configuration, including both 
file based and registry based, can be user specific and system wide. The application 
deBvery system used should mark each file for which of these types any file is. This 
mformation provides hints to tiie pperatmg System Guard system to act on appropriately. 

DEVICE DRIVERS 

Many applications use device drivers or other operating system, level software to 
implement some of its functions such as hardware support or low leve;l interactions 
dkectly with the operating system la the present mvention, the Operating System Guard 
will provide the capability of dynamicaUy, and as possible privately , adding and 
removing these components to an application's virtual environment:. 

Many device drivers are built to be dynamically loadable. If at all possible, it is 
the preferred embodiment to load all device drivers dynamically. If a device driver 
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requires static load at boot time, the user must be presented wtb this knowledge before 
miming the apphcation. Once the system has rebooted, the application should continue 
from where it left off However, a large percentage of device drivers are not dynamically 
unloadable. Although it is preferred to dynamically unload the driver, if this cannot be 
accomplished the driver will be marked for removal on the next reboot, and the user 
should be ntiade aware of this. If the application is run a second time before the next 
reboot, the system should remain aware of the presence of the driver and not Bttewpt a 
second installation, waiting for tennination to remark the component removable at next 
reboot. 

It is important to characterize the base similarities and dififerences, as ihey exist 
for each device driver class, to ensure the present invention can correctiy fimction. It is 
not truly desired to load and unload device drivers for system hardware that is constantly 
preset It should be understood that although this is not a preferred embodiment 'in 
terms of programmiag ease, it is within the scope of the present invention and roay be 
required for specific reasons, such as the restriction in licensmg agreements for 
applications that are delivered and run u^g the present mvention. 

On non-Microsofi platforms, device drivers are typically handled very differently. 
Macmtosh systems support both static and dynamic drivers, but they are all installed and 
removed through the same method. Linking with the Macintosh system folder will 
provide the necessary support. For UNIX systems, device drivers most typically require 
a modification to the running UNIX kernel, followed by a reboot. This process can be 
very con^lex. In the preferred embodiment, this process is automated; including 
resetting the kernel once the application is complete. The general parameters of the 
process are the same as that described above for Windows applications, the actual process 
steps of con5>ilation and persons familiar with such operating systems can carry out 
reboot 
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FinaDy^, those of skill in the art will understand that it is desirable to be able to 
recover and remove drivers across system fiilures. Whatever data or processes necessary 
to retain system integrity are therefore a preferred embodiment of the present invention. 
Those of skill in the art will also appreciate that all types of device drivers might not be 
conveniently or efficiently provided via the present invention, most particularly those 
associated with, permanent hardware attached devices. 

OTHER ITEMS 

In the present invention, it is recognized that there are several components of the 
invention, the behavior or presence of which is different on alternate operating systems. 
These con:q>onents include fonts, processes, environment variables, and others. 

Some applications require fonts to be installed in ordear to perform correctly. Any 
fonts required will be specified in the Operating System Guard's configuration file. The 
Operating System Guard will enable these fonts prior to runoing the application and if 
necessary remove them afterwards. Most systems have a common area for storage of 
fonts in addition to a process for registering them or making the system aware of their 
presence, the Operating System Guard will utilize these available methods. 

On Windows, a font is copied to the \WINDOWS\FONTS directory. This 
however does not guarantee that the font is available to the running progranu In the 
preferred embodiment, if the program uses the Windows API to access fonts, the font will 
need to be registered with a Win32 API call such as CreateScalableFontResource/ . 
AddFontResouice. This will insert the font into the system font table. Once conqjlete, 
the Operating System Guard can remove the font with another appropriate API call like 
RemoveFontResource, then remove the file fiom the system As an alternate 
embodiment, the Operating System Guard could hook the API functions as described in 
the virtual registry method. In addition, the Operating System Guard can use its File 
subsystem to avoid placing the actual font file in the running system* 

On Macintosh, the process is extremely sunilar and based on files hi the 
Madntosh system folder and registration activation. On UNIX, however, the process is 



-14- 



wo 02/093369 



CA 02465880 2003-11-14 



PCTAJS02/15378 



dependent upon the application. Most typically, font resources are added to the system as 
regular files resolved m the proper location, so they can be accessed by name. With 
many Motif systems, a font description needs to be placed into a font resource file, which 
will allow the font to be resolved. The Motif or X application can invoke the font either 
through the resolution subsystem or by a direct call. Recentiy, many Motif and CDE 
based systems utilize Adobe scalable postscr5)t fonts. These fonts need to managed 
through the Adobe type management system There are exceptions, however, and as 
stated above, there are alternates to the Windows or other operating system default font 
management systems. The Adobe Type Manager provides some alternate inter&ces for 
this process, as do other third party type management systems. In most cases it sJiould be 
decided whether to support the interface or ignore it. The purpose of Operating System 
Guard is not to provide a universal layer for all these systems, only to do so for the 
operating system's own subsystem 

Many applications require environment variables to be set. This is most conmion 
on UNIX systems, but is also heavily used by software, which was originally written on 
UNIX and ported to the Windows operating systems. Applications on tiie Windows 
operating systems heavfly rely on the DOS PATH environment variable and often set 
then: own application specific entries. On the Windows 9x/Me environments, there are 
many environment settings, which are applicable as at its core is the DOS subsystera If 
an application requires the presence of specific variables, or values to be set bx existing 
environment variables, the required environment variables will be specified in the 
Operating System Guard's configuration file. The Operating System Guard will set these 
variables for the application's main process when it is laimched. As applications do not 
typically change environment settings as they operate, the virtual environment will not 
trap these calls, nor will it provide the fiiU complement of fimctionality that the registry 
and configuration subsystem does. 

RECOVERY 

In some cases shovm in the previous sections, actual modifications must be made 
tothe operating system. This is fireqaent -vvith. device drivers and fonts. Li addition. 
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changes can be made to the virtual environment that need to be persisted and available 
the next time an application is nm. It is required that the Operating System Guard system 
be able to recover from changes to the system, removing the change from the system at 
its earBest possible opportunity. Alternately, if the system crashes during an 
application's execution, the Operating System Guard should track enough informatiou to 
remove any change to the system if it is rebooted or otherwise, and should track the 
changes made to the virtual environment. In the preferred embodiment, this is 
implemented as a transaction log, but can in other embodiments be done as some other 
i^btnilar con^onent, vMch can be read on system startup so that changes can be backed 
out. 

CONTROLLING VIRTUAUZATION 

An important aspect of the invention relates to control of the many fecets of 
virtualization which the Operating System Guard is capable o£ In the prefened 
embodiment there exists an instrumentation program able to ascertahi the correct aspects 
of a software system to control Also included is a method to allow administrators and 
end users to view and modify those items to be virtualized by the system. 

In the automated program, the application to be controlled is observed in order to 
gauge the aspects of control The automated program is capable of performing this task 
during the installation process of the application, during run-time of the application, or a 
combination of botk Jn the preferred embodiment, the Operating System Guard is 
embedded in a wrapper application. Post installation, or after one or many uses of the 
software, the wrapper application will query the Operating System Guard for a detailed 
list of aU of its actions. From this list of actions, the wrapper appUcation will create the 
configuration files required to load and operate the Operating System Guard on 
subsequent uses. 

If used as part of the installation process, the Operatinjg System Guard, in the 
preferred embodiment, will act as a virtual layer allowing the installation to be entered 
into its environment only. After the installation, all of the files, settings, et. al can be 
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duiDped for reload later. la this way, the installation will leave the original system intact 
and will have automatically created the necessary configuration files. When used during 
use of the application, the Operating Systrai Guard is ahle to record either differential 
modifications to the environment, or recodify the configuration files. 

The Operating System Guard wiU pass its information to the wrapper appfication 
for post-processing. In the preferred embodiment, in addition to the automatic entries 
that the system can create, the wrapper application is programmed with operating system 
specific and application or domain specific knowledge. This knowledge is used to alter 
the output of the process to reflect knovwa uses of configmration items or other entries. In 
the preferred embodiment, a rules^based system is enqjloyed to con^are observed 
behaviors with known scenarios in order to eflfect changes to the coding. 

The wrapper application is also used as a viewer and/or editor for the 
configuration output of the process. This editor, in the preferred embodiment, enables a 
system administrator to add, edit, or delete items or groups of items firom the 
configuration. In observing the configuration through the editor, the administrator can 
also make replicas of the configuration, changing specific items as needed to effect 
application level or user custom changes 

Referring now to FIG. 1, an embodiment of the present invention jjs illustrated 
functionally. In this embodiment, two sets of application/user data 60 are illustrated. 
The Operating System Guard 1 00 keeps the two instances of the application 50 from 
interfering with one another. In addition, as e^lained above, the operating system guard 
100 serves as an abstraction layer and as such collects commands and commimications 
between the application software 50 and the actual operating system 10 of the client 
coEq)uter. As illustrated graphically by the arrows, certain commands are between the 
Operating System Guard and the software application, this is in distinction to typical 
installations where these commands would instead be acted upon by the operating system 
itseb^ resulting in changes to the client computer that might not necessarily be wl^at the 
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operatoT intended. On the other hand, other commands pass through the Operatmg 
System Guard and are tiien transferred to the Operating System itsel£ 

While this invention has been particularly shown and described with references to 
preferred embodiments thereof it will be understood by those skilled in the art that 
various changes in form and details may be made therem without departing from the 
scope of the invention encompassed by the appended claims. 
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What is claimed is: 

1. A system for creating an appEcation soflware eavironment without changing an 
operating system of a client computer, the system coir^prising an operating system 
abstraction and protection layer, wherein said abstraction and protection layer is 
interposed between a nnming software application and said operating system, whereby a 
virtual environment in which an application may run is provided and application level 
interactions are substantially removed. 

2. The system of claim 1, \N^erein changes directly to the operating system are 
selecth^ely made within the context of the running application. 

3 . The system of claim 2, wherein the abstraction and protection layer dynamically 
changes the virtual environment according to administrative settings. 

4. The system of claim 1, wherein the system contuiually monitors the use of shared 
system resources and acts as a sendee to apply and remove changes to system 
conqponents. 

5. The system of claim 1, whereia the operating system is a Windows-based operating 
system, and wherein all operations to the Windows Registry and .ini files are through the 
Wiii32 API, the system fiirther comprising a means for hooldng fimctions, whereby each 
time said functions are invoked another function or application intercepts the caU. 

6. The system of claim 5, wherein the system hooks each appropriate API function to 
service a request whether made by an application run from a server or if made by an 
appUcatioh against a configuration key beiag actively managed 

7. The system of claim 1, wherein said operating system abstraction and protection layer 
manages the integration of multiple instances of an application by recogntring how.many 
instances of an application are running. 
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8. The system of claim 7, wherein said operating system abstraction and protection layer 
avoids making changes on startup and shutdown uiiless there is only one application 
instance running. 

9. The system of claim 1, wherein said operating system abstraction and protection layer 
presents an enviroimient to an application that appears to be an installation environment 
without performing an installation, whereby a **l)seudo installation'* is created in which 
all of the settings are brought mto a Aortual environment at the time the application runs. 

10. The system of claim 9, finrther con5)rising a means for preventing information on the 
client conogputer from interfering or modifymg the behavior of an application. 

11. The system of claim 9, fixrther con:q>iishig a means for dynamically changing the 
virtual environment according to administrative settings. 

12. The system of claim 9, wherein more than one histance of a single sofiware 
application runs on the same client coioputer, and wherein each of said more than one 
instance coimects f o a diOerent database 

13. The system of claim 12, wherem shared, controlled contexts are provided in which at 
least two of said instances of a single application share one or more virtual settings. 

14. The system of claim 1, fiirther coiiq)rising a device driver monitor that receives 
instructions at the time of installation for a particijlar application. 

15. The system of claim 1, fiirther corc5)rising a virtual Windows Registry conq)onent to 
provide a full function registry to an application, but prevent modification to the 
underlying system registry. 
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16. The system of claim 1, wdierein the operating system abstraction and protection layer 
responds with a key and its value if said key and value are stored within the operating 
system abstraction and protection layer, if not stored, the operating system abstraction 
and protection layer allows the request to pass through to the Windows Registry. 

17. The system of claim 16, wherein if an atten5)t is made to modify the value of said 
key, the operating system abstraction and protection layer allows the modification to 
occur to itself only. 
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